Published on Apr 02, 2024
Generic Framing Procedure (GFP) is defined by ITU-T G.7041. This allows mapping of variable length, higher-layer client signals over a transport network like SDH/SONET. The client signals can be protocol data unit (PDU) oriented (like IP/PPP or Ethernet Media access control [MAC]) or can be block-code oriented (like fiber channel).
There are two modes of GFP, viz., GFP-F and GFP-T. GFP-F maps each client frame into a single GFP frame. GFP-T, on the other hand, allows mapping of multiple 8B/10B client data frames into an efficient 64B/65B block code for transport within a GFP frame.
GFP utilizes a length/HEC-based frame delineation mechanism that is more robust than that used by HDLC (High-level Data Link Control), which is single octet flag based.
There are two types of GFP frames: a GFP client frame and a GFP control frame.
This clause discusses the common (protocol independent) aspects of GFP for octet-aligned, variable-length payloads. The mapping of the framed payloads into a STS SPE is specified in ANSI T1.105.02. The mapping of the framed payloads into an OTN ODUk payload is specified in ITU-T Recommendation G.709. GFP uses a variation of the HEC-based frame delineation mechanism defined for ISDN Asynchronous Transfer Mode (ATM) (see ITU-T Recommendation I.432.1-1999). Two kinds of GFP frames are defined: GFP user frames and GFP control frames.
Frame formats for GFP user and control frames are defined in clauses 6.1 and 6.2. Common handling procedures for all GFP frames are specified in clause 6.3. GFP also supports a flexible (payload) header extension mechanism to facilitate the adaptation of diverse transport mechanisms via GFP. Currently defined (payload) extension header types are specified in clause 6.4. Unless otherwise stated all fields in the GFP frame are represented in Network Octet Order (NOO), and all octets are represented in Network Bit Order (NBO), with bit 1 being the most significant bit (MSB) and bit 8 being the least significant bit (LSB).
A GFP client frame can be further classified as either a client data frame or a client management frame. The former is used to transport client data, while the latter is used to transport point-to-point management information like loss of signal, etc. Client management frames can be differentiated from the client data frames based on the payload type indicator. The GFP control frame consists only of a core header field with no payload area. This frame is used to compensate for the gaps between the client signal where the transport medium has a higher capacity than the client signal.
GFP uses a modified version of the HEC check algorithm specified in ITU-T I.432, clause 4.5.1.1, to provide GFP frame delineation. The frame delineation algorithm used in GFP differs from that in ITU-T I.432 in two basic ways:
a) The algorithm uses the PDU Length Indicator field of the GFP Core Header to find the end of the GFP frame; and
b) HEC field calculation uses a 16-bit polynomial and, consequently, generates a two-octet cHEC field. GFP frame delineation is performed based on the correlation between the first two octets of the GFP frame and the embedded two-octet cHEC field. Figure 13 shows the state diagram for the GFP frame delineation method. The state diagram works as follows:
1) In the HUNT state, the GFP process performs frame delineation by searching, octet by octet, for a correctly formatted Core Header over the last received sequence of four octets. Core Header correction is disabled while in this state. Once a correct cHEC match is detected in the candidate PLI and cHEC fields, a candidate GFP frame is identified and the receive process enters the PRESYNC state.
2) In the PRESYNC state, the GFP process performs frame delineation by checking, frame by frame, for a correct cHEC match in the presumed Core Header of the next candidate GFP frame. The PLI field in the Core Header of the preceding GFP frame is used to find the beginning of the next candidate GFP frame. Core Header correction is disabled while in this state. The process repeats until DELTA consecutive correct cHECs are confirmed, at which point the process enters the SYNC state. If an incorrect cHEC is detected, the process returns to the HUNT state. The total number of consecutive correct cHECs required to move from the HUNT state to the SYNC state is therefore DELTA + 1.
3) In the SYNC state, the GFP process performs frame delineation by checking for a correct cHEC match on the next candidate GFP frame. The PLI field in the Core Header of the preceding GFP frame is used to find the beginning of the next candidate GFP frame. Single-bit Core Header correction is enabled while in this state. Frame delineation is lost whenever multiple bit errors are detected in the Core Header by the cHEC. In this case, a GFP Loss of Synchronization event is declared and the framing process returns to the HUNT state and a GFP Server Signal Failure (SSF) is indicated to the client adaptation process.
4) Idle GFP frames participate in the delineation process and are then discarded. Robustness against false delineation in the re-synchronization process depends on the value of DELTA. The parameter DELTA is to be chosen to make the GFP frame delineation process as robust and secure as possible. A value of DELTA=1 is suggested.
| Are you interested in this topic.Then mail to us immediately to get the full report.
email :- contactv2@gmail.com |
